Auditing of charges in an integrated prevalidation and ordering system

ABSTRACT

Disclosed is a system that prevalidates service orders that are placed by an inter exchange carrier with a local exchange carrier for connection of the inter exchange carrier with a business customer. An integrated prevalidation system and service order system is disclosed in which prevalidation requests are performed using the data that is entered for the service order. Prevalidation responses are then used to ensure that the order will be correct when submitted, thereby avoiding, the necessity for expensive supplemental orders. Further, the present invention allows for stand alone prevalidation requests which enable a provisioner to determine availability of circuits, and to determine location information and equipment identification directly from the LEC databases. Further, the present invention is capable of reconciling the database of the inter exchange carrier with the database of the LEC to avoid submission of incorrect service orders. Further, auditing reports can be generated whenever a prevalidation response has been accepted and a service order acknowledgment has rejected the service order. These reports can be used to audit and obtain credit for the necessary supplemental orders which may follow. Also, prevalidation requests are reserved to prevent submission of conflicting service orders.

FIELD OF THE INVENTION

[0001] The present invention pertains generally to telecommunicationsand, more particularly to a system for prevalidating orders with a localexchange carrier.

BACKGROUND OF THE INVENTION

[0002] Inter exchange carriers such as MCI, that provide long-distanceservice to customers, frequently place access service requests withlocal exchange carriers to establish voice and data connections. Hence,the inter exchange carriers, such as MCI, have to deal with a number ofdifferent local exchange carriers that provide the local service forthese customers. Typically, the local exchange carrier will make certainservices available to business customers within the LEC's service area.For example, a LEC may provide a certain number of T1, T3, OC-48, etc.services that are provided between the customer and the LEC centraloffice.

[0003] The business customer may wish to either activate or deactivateits voice and data services as business needs either increase ordecrease, respectively. For example, if a business customer desires toincrease its service, a representative of the business customer willnormally contact its inter exchange carrier by phone and make a requestfor the additional service. The provisioner (order taker) located at theinter exchange carrier takes the request from the business customer. Theprovisioner then processes the request on a prevalidation system. Theprevalidation system allows the inter exchange carrier to access thedatabase of the applicable LEC to determine the availability of channelsfor the requested service. In other words, the prevalidation systemobtains the circuit identification for the channels that are to beprovided by the LEC to fulfill the service order.

[0004] Upon receiving this information from the LEC database, theprovisioner then enters access service requests (ASRs) using a separateordering system. The provisioner performs this task by keyboarding allof the detailed information regarding circuit ID's, service locations,service requests and other detailed information into an ASR orderingsystem. In the process of performing this task, errors can be easilymade by the provisioner. Further, other provisioners of the interexchange carrier may have also received requests from otherrepresentatives of the same business customer at approximately the sametime which could result in the duplicate assignment of the same circuitIDs. However, the primary concerns of the inter exchange carrier arethat this type of dual system of prevalidation and rekeying of data intoan automatic service request system are

[0005] (1) the time delay in placing the order, and

[0006] (2) the costs and delays associated with the necessity togenerate supplemental orders whenever the LEC rejects the servicerequest.

[0007] A great deal of effort must be expended in entering the detailedand extensive information of an automatic service request. Very oftenthe provisioners become very busy and are unable to prepare the servicerequest immediately after it is requested by the business customer.Further, the inherent delays in placing an incorrect order, having thatorder rejected and preparing a supplemental order can be costly to theinter exchange carrier. Such a process of submitting a supplementalorder may result in several days of delay. Additionally, it costs theLEC time and money for the provisioner to prepare and submit thesupplemental order.

[0008] Although prevalidation systems have been very effective inreducing the costs associated with submitting supplemental orders as aresult of mistakes in service orders, it would be advantageous toprovide a system that further eliminates errors that can occur in theactual ordering process and to provide an integrated system that canautomatically prevalidate orders as part of the process of placing anorder.

[0009] Further, it would be advantageous to provide a system that iscapable of generating reports that are useful in analyzing errors thathave been made by the LEC. For example, in an integrated system thatautomatically prevalidates orders as part of the process for placing anorder, a rejected acknowledgment may be received from the LEC. Since theservice order was prevalidated just prior to placing the order, arejected acknowledgment should not have been received. It wouldtherefore be advantageous to generate reports that audit these types oferror produced by the LEC so that credit can be obtained for charges onsupplemental orders that are necessitated by the rejected orderacknowledgment.

SUMMARY OF THE INVENTION

[0010] The present invention overcomes the disadvantages and limitationsof the prior art by providing a system that is capable of generatingreports indicating errors made by the LEC and that may be used forauditing LEC charges.

[0011] The present invention may therefore comprise a method of auditingan integrated prevalidation and ordering system in which service ordersare placed by an inter exchange carrier with local exchange carriercomprising: obtaining prevalidation responses and service orderacknowledgments in response to generation of a service order on theintegrated revalidation and ordering system: generating a file of theprevalidation responses and service order acknowledgments for eachservice order that has a rejected acknowledgment and an acceptedprevalidation response; using said file to audit charges incurred by theinter exchange carrier for the service orders.

[0012] The present invention may further comprise a system for auditingcharges incurred by an inter exchange carrier for supplemental ordersnecessitated by rejected acknowledgments of a service order thatreceived an accepted prevalidation response in an integratedprevalidation and order system comprising: a prevalidation system thatgenerates prevalidation requests and receives prevalidation responses inresponse to preparation of a service order in an integratedprevalidation and ordering system; an ordering system connected to theprevalidation system and a local exchange carrier that generates a fileof accepted prevalidation responses and rejected service orderacknowledgments, and generates a report from the file to audit thecharges incurred by the inter exchange carrier.

[0013] The advantages of the present system are that prevalidationrequests can be made automatically as part of an ordering system sincethe prevalidation ordering system and the ordering system are integratedinto a single system that utilizes at least a portion of the same data.In this fashion, the need to reenter data into the ordering system thathas already been entered into the prevalidation system is eliminated.Errors that can potentially occur upon reentering data are avoided.Further, delays and costs associated with preparation and submittal ofsupplemental orders can be substantially eliminated.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014]FIG. 1 is a schematic diagram illustrating the relationship ofinter exchange carrier offices with local exchange carrier centraloffices and business customers in two different cities.

[0015]FIG. 2 is a schematic block diagram of the separate systems usedfor prevalidation and ordering.

[0016]FIG. 3 is a schematic block diagram of the integrated system ofthe present invention.

[0017]FIG. 4 is a screen printout of a CFA inquiry.

[0018]FIG. 5 is a screen printout of a response to a CFA inquiry.

[0019]FIG. 6 is a screen printout of a location inquiry.

[0020]FIG. 7 is a screen printout of a response of location inquiry.

[0021]FIG. 8 is a screen printout of a service inquiry.

[0022]FIG. 9 is a screen printout of a response to service inquiry.

[0023]FIG. 10 is a more detailed block diagram of the integrated systemof the present invention.

[0024]FIG. 11 is an ASCII file of CFA prevalidation requests.

[0025]FIG. 12 is an ASCII file of responses to CFA prevalidationrequests.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0026]FIG. 1 is a schematic illustration of the manner in which an interexchange carrier is connected to provide long distance data and voiceservices to business customers through local exchange carriers (LECs).As shown in FIG. 1, an inter exchange carrier has an inter exchangeoffice 10 that is located in city A that is indicated by referencenumeral 12. The inter exchange office 10 is connected to an interexchange office 14, located in city B that is indicated by referencenumeral 16, by way of an intercity trunk 18. Intercity trunk 18 mayconstitute a fiberoptic trunk, a microwave link or other communicationlinks.

[0027] As also indicated in FIG. 1, the inter exchange carrier office 10is connected via the high speed connections 25 to a series of localexchange carrier central offices 18, 20 in city A. Similarly, the interexchange carrier office 14, that is located in city B, is connected toone or more local exchange carrier central offices 22, 24 via the highspeed connections 26. Each of the local exchange carrier central officesis connected to a number of business customers. For example, the LEC CO18 is connected to business customers 28, 30, LEC CO 20 is connected tobusiness customers 30, 34, LEC CO 22 is connected to business customers36, 38, and LEC CO 24 is connected to business customers 40, 42.

[0028] As can be seen from FIG. 1, for a business customer, such asbusiness customer 28 to obtain the high speed data services offered bythe inter exchange carrier, the local exchange carrier central office 18must provide a connection to the inter exchange carrier office 10.Typically, the business customer 28 calls the inter exchange carrier andasks to have those services provided. The inter exchange carrier thencontacts the local exchange carrier to provide the proper connections 44from the business customer 28 through the central office 18 to the interexchange carrier. These requests by the inter exchange carrier of thelocal exchange carrier are referred to as access service requests (ASR).The present invention allows the inter exchange carrier to query thebackend systems of the local exchange carrier in realtime to obtaininformation relevant to (1) location, (2) service availability, and (3)connecting facility assignment (CFA).

[0029]FIG. 2 is a schematic illustration of a typical system that iscurrently in use but does not employ the aspects of the presentinvention. As shown in FIG. 2, a business customer 46 places a standardtelephone call through the public switched telephone network 48 to aprovisioner 50 that is employed by the inter exchange carrier 52. Thebusiness customer 46 may request services Such as additional T1services. T3 services, etc. The provisioner 50 then determines which LECprovides service to the business customer 46. Provisioner 50 thenaccesses an interface device, such as interface devices 54, 66, or 72for obtaining a prevalidation of the requested service. For example,business customer 46 may be connected to LEC 52. In that case, theprovisioner 50 would access an interface device 54 that is connected toa proprietary prevalidation system 56. For example, the proprietaryprevalidation system 56 provides access to a log-in screen on amainframe, operated by LEC 52 via the interface device 54 to obtainaccess to certain prevalidation information. That information can thenbe used by the provisioner 50 to be entered in the interface device 58that is provided to the automatic service request system 60 and thenetwork data mover (NDM) ordering system 62 to order the services fromLEC 52.

[0030] Other LECs, such as LEC 64, may have a password protectedInternet web page that 20 the inter exchange carrier 52 can access. Forexample, provisioner 50 may utilize the interface device 66 to providean Internet connection 68 to a password protected web page provided byLEC 64. The password protected web page may provide certain informationthat can be used by the provisioner 50 to place an order through the ASRSystem 60 by separately entering that data in the interface device 58.

[0031] Further, some LECs, such as LEC 70, merely provide information byphone. The provisioner 50 must place a telephone call on telephone 72through the public switched telephone network 74 to the LEC 70 to obtainprovisioning information that can then be used by the provisioner 50 toenter into the interface device 58. Also, some LECs, such as LEC 76, mayhave no process available for obtaining provisioning information.

[0032] As also shown in FIG. 2, the process of actually placing an orderthrough a particular LEC is performed by the provisioner 50 by enteringdata into the interface device 58. An industry standard electronic formis completed by the provisioner 50 that includes the connecting facilityassignment (CFA), the location of the access points for the businesscustomer, service availability and a large amount of additionalinformation. The CFA is a data structure that includes the facilitytype, facility designator and indicates the channels that are beingrequested. The location information indicates the location of the accesspoint of the business customer to the LEC CO. on one side, and thelocation of the access point of the inter exchange carrier to thebusiness customer at the local exchange carrier central office, on theother side. Provisioner 50 completes the electronic form that is sent tothe automatic service request system (ASR) 60. The NDM system 62 is abatch program that runs periodically throughout the day and collects allof the ASRs for a specific LEC. Periodically, the NDM system 62 thensends out all of the pending ASRs for a specific LEC. The NDM system isa commercially available system that complies with standard transferprotocols. The NDM system 62 defines an interface between the ASR 60 andLEC mainframe for placing orders with LECs. The NDM system provides aprotocol that is designed to transfer data between the LEC mainframe andthe ASR System 60. The NDM system 62 is commonly used in the industryfor interfacing inter exchange carriers with LECs to send ASRs.

[0033] Once the ASR has been transmitted to the LEC mainframe, the LECmainframe reviews the ASR electronic forms to verify the completenessand correctness of the ASR. The LEC mainframe then transmits anacknowledgment of the request. The acknowledgment may indicate that theorder is correct and complete and has been accepted, or theacknowledgment may indicate any errors in the ASR. For example, theacknowledgment may indicate that there is an error in the CFA, or thelocation information. If the order is rejected, a supplemental ordermust be prepared and sent through the system in the same fashion.

[0034] For each original ASR order and for each supplemental ASR order,a fee must be paid by the inter exchange carrier 52. The provisioner 50has placed the order with knowledge of what the provisioner thinks arecorrect CFAs, locations and service request information. Because ofother orders going through the system and errors that may be made by theprovisioner 50 in entering data in the electronic form in the interfacedevice 58, supplemental orders may frequently be required. Typically,the facilities of each business customer are designated for each interexchange carrier. In other words, inter exchange carriers are notnormally competing for the same facilities. Hence, databases can be keptby the inter exchange carrier 52 to determine what facilities the interexchange carrier thinks may be available. This avoids the necessity ofthe inter exchange carrier 52 contacting the LEC to determine theavailable facilities. Additionally, provisioners 50 typically have beenisolated to single accounts. In this fashion, provisioners becomefamiliar with what facilities are available and the location of thosefacilities for each business customer. However, errors can stillfrequently be made because of typos in entering the data and incorrectinformation that may have persisted for some time. For example, varioussystems may have been running for years and information may become lostor are inaccurate. An inter exchange carrier 52 may show that aparticular connection was disconnected, while the LEC system stillthinks that that connection is active. These types of problems have ledto an increased need for a standard method of prevalidating orders.

[0035] There is a substantial cost incurred for rejected orders. Thedelays in the connection of the customer to the system may damagecustomer relationships between the inter exchange carrier and thebusiness customer and decrease revenues of the inter exchange carrierduring the delay period. Further, the additional labor of theprovisioners 50 in reentering data as supplemental orders is also costlyto inter exchange carriers, as pointed out above.

[0036] Industry standards have been adopted for prevalidation systems toprovide a standard way of prevalidating orders. Original standards weredeveloped by the Order Billing Forum (OBF) which instituted the idea ofa standardized prevalidation system. The T1M1 Committee of the OBF thenadopted standards upon which the system of the present invention isbased. The standard has essentially adopted a gateway-to-gatewayinterface between the LEC backend and the inter exchange carrierprevalidation system. The standard was written with the Common ObjectRequest Broker Architecture (CORBA) as the communications standard forthe gateways. CORBA allows disparate applications to communicate withone another. The T1M1 committee initially provided and defined theInterface Definition Language (IDL). The ORB is the middleware thatestablishes the client/server relationships between objects. Using anORB, a client can transparently invoke a method on a server object,which can be on the same machine or across a network. The ORB interceptsthe call, and is responsible for finding an object that can implementthe request, passes the perameters, invoke its method and then returnthe results. The client does not have to be aware of where the object islocated, its programming language, its operating system, or any othersystem aspects that are not part of the object's interface. In so doing,the ORB provides interoperability between applications on differentmachines in heterogeneously distributed environments, and seamlesslyinterconnects multiple object systems.

[0037] The standards, however, relate to a prevalidation system and notthe ASR/NDM system. For these reasons, a prevalidation systemincorporating these standards has typically been separate from theASR/NDM system.

[0038]FIG. 3 is a schematic illustration of a system that implements thepresent invention. The system illustrated in FIG. 3 integrates themainframe ordering system of the inter exchange carrier 78 with aprevalidation system. In accordance with FIG. 3, a business customer 80may place a telephone call via the public switch telephone network 82 toa provisioner 84 located at the inter exchange carrier premises 78. Thebusiness customer 80 may request additional services such as additionalT1 services. The provisioner 84 can then enter the request in theinterface device 86, Such as personal computer that is connected to anetwork 87. The provisioner 84 can log onto the mainframe 88, or theprevalidation system 91, using the network connector 87. By logging ontothe prevalidation system 91, stand alone prevalidation requests can bemade to obtain provisioning information. By logging onto the mainframe88, an integrated process of prevalidating orders and placing orders canbe performed. This integrated process uses the prevalidation system 91and employs the electronic forms of the ASR 176 to generateprevalidation requests. Actual orders are placed using ASR 176 and NDM108, which is explained in more detail below. Prevalidation calls areplaced from the mainframe 88 to the integrated server 90 ofprevalidation system 91. These requests pass through middleware 93 thatperforms various functions described in more detail below. The requestsare then passed to gateway 92 that transmits the requests to theappropriate LEC which may constitute LEC 96, 100, 104. The gatewaycommunicates these requests to corresponding gateways 94, 98, 102. Therequests are transmitted via secure T1lines 106. Orders from the NDM 108are placed through secure T1 lines 110 to the appropriate LEC. Gateway92 and gateways 94, 98, and 102 employ the CORBA middleware that is ableto transmit a prevalidation request to the gateways located at the LECs.

[0039] The prevalidation requests are followed by responses from the LECthat are transmitted from the LEC gateway-to-gateway 92 of the interexchange carrier 78. These responses are then transmitted to themiddleware 93 and integrated server 90, and back to the mainframe 88 andinput device 86 where the provisioner 84 can view the response.Provisioner 84 can then use the data from the response, add further datathat may be required to place the order, and then send the order onmainframe 88 as an access service request (ASR).

[0040] In operation, the provisioner 84 may complete different pages ofthe access service request upon receiving an order from a businesscustomer 30. As each form of the ASR is completed, calls areautomatically made through the integrated server 90, middleware 93 andgateway 92 to the appropriate gateway at the LEC. In this manner, dataentered from the input device 86 is transmitted to the LEC as soon as itis sufficiently complete.

[0041] Once the ASR data is complete from the responses that arereceived by the prevalidation system, an ASR order may be placed throughthe NDM 108 via secured lines 110 to the appropriate LEC. The LEC thenprovides an acknowledgment of the ASR that either indicates that the ASRis complete and correct, or that it contains errors. Further, the LECsystem is designed to indicate the type and location of the errors. Allof this information is stored on storage device 112. If Such errors arepresent, the provisioner 84 can make corrections to the ASR and resubmitthe request as a supplemental request.

[0042] The system illustrated in FIG. 3 provides a capability ofquerying the backend systems of the LECs in real time for informationthat is relevant to (1) location, (2) service availability, and (3)connecting facility assignment (CFA). The preorder validation systemsignificantly reduces the number of supplemental ASRs that are sent tothe LECs to correct rejected data. In addition, the system illustratedin FIG. 3 provides critical provisioning information to the interexchange carrier using the stand alone prevalidation requests. Thisinformation can then be used for future provisioning.

[0043] In that regard, the CFA information indicates the channels thatexist within a leased facility that extend from the customer's actualcontrol terminal location (ACTL) to a serving wire center (SWC), whichis normally the LEC CO, as indicated in FIG. 1. The stand aloneprevalidation process allows a provisioner to retrieve the status andrelevant information from the LEC for specific channels, or a range ofchannels, of the CFA. The present application allows queries at the T1through fiber levels.

[0044]FIGS. 4 through 9 illustrate various stand alone screens that canbe accessed by the provisioner 84 using the input device 86. Theintegration process utilized in accordance with the present inventionmay incorporate data that is shown in these screens and place calls fromthe mainframe 88 to the LECs to automatically retrieve this data.However, FIGS. 4 through 9 also provide an indication of the type ofrequests that are made automatically using the integrated process of thepresent invention.

[0045]FIG. 4 is an illustration of a CFA inquiry. In this case, theprovisioner may wish to determine the availability of channels in a CFA.As indicated in FIG. 4, a pull-down box 110 is used to select aparticular LEC. For example, Southwestern Bell Corporation is shown inthe pull-down box 110. The provisioner then inserts information in theCFA inquiry input section 112. Facility designators, as well as facilitytype and location A and location Z, are input by the provisioner 84.Additionally, channel information may be inserted, or the channel boxmay be left blank to determine the available channels. The provisioneris normally familiar with the facility designator input whichconstitutes the equipment ID on which the particular CFA inquiry isbeing made. The facility type is a particular type of service requestedsuch as T1, T3, etc. Location A, as described above, is the location forthe access of the inter exchange carrier in the local exchange centraloffice. Location Z is the access point of the business customer to thelocal exchange carrier central office.

[0046] As also shown in FIG. 4, the prepopulate option box 114 allowsthe provisioner to enter NetPro circuits or NetPro order numbers (i.e.,mainframe IDs) if the provisioner is familiar with that data to obtaindesired information. Once the information is entered, the send box 116is activated and calls are placed through the system illustrated in FIG.3 to the LEC backend. The requested information is then returned, asindicated on the output choices box 118. The status box indicates thestatus of the data. A “gateway sent” response indicates that the CFAinquiry has been sent through the gateway to the LEC and no response hasyet been received. A “reply complete.” which is not shown in the list,indicates that a reply has been received from the LEC backend and hasbeen stored as part of the functions of the prevalidation system 91 thatis shown in FIG. 3. The status “reply seen” indicates that theprovisioner has accessed the database in the prevalidation system 91(FIG. 3) and has retrieved the data for review. The LEC ID box indicatesthe particular LEC which, in this case is Southwestern Bell Corporation.The date box indicates the date and time of the action indicated in thestatus box. The ID box indicates the ID that has been assigned by theprevalidation system 91 (FIG. 3). The CFA box indicates the ID of theCFA that corresponds to the CFA inquiry input. Any of the rows ofinformation shown in the output choices 118 can be double clicked toretrieve more detailed data.

[0047]FIG. 5 is a screen that indicates that the first row ofinformation in the output choices box 118 of FIG. 4 has been doubleclicked to bring up additional information regarding that particularCFA. Of course, the status of the first line changed from “gateway sent”to “reply complete” prior to double clicking on the first row. As shownin FIG. 5, additional data is shown for the CFA that is indicated in theselection tab 120. The IRI indicates that the particular CFA that wasbeing requested was found. The ID indicates the prevalidation system IDnumber that corresponds to the ID number of the first row of the outputchoices of FIG. 4. The LEC field identifies the LEC, which isSouthwestern Bell Corporation. The CFA inquiry input box 122 indicatesthe particular data that was entered in the CFA inquiry input box 112 ofFIG. 4. In other words, the CFA inquiry input box 122 is an indicationof what was requested in box 112 of FIG. 4.

[0048] As also shown in FIG. 5, the CFA output 124 provides the responsefrom the LEC as to which channels are available for the particular CFAthat was requested. As shown in FIG. 5, channels 1 through 20 areavailable since the status indicates “spare.” Channel 21 has a “pending”status which indicates that there is probably a connection order that ispending for that particular channel. CFA output 124 also indicates thatchannels 22 through 24 for that particular CFA T1 line are alsoavailable. Since the channel information was left blank in the CFAinquiry input 122, the full range of availability of channels isprovided in the CFA output 124. This assists the provisioner inassigning channels for the ASR request when an order is placed.

[0049]FIG. 6 is a screen print of a location inquiry that has been madeby the provisioner. In other words, the provisioner 84 (FIG. 3) isdetermining information relating to physical locations that arenecessary for inclusion in the ASR request. FIGS. 6 and 7 provide thelocation information that may be required by the provisioner to completethe ASR request. As shown in FIG. 6, a drop down box is used to selectthe type of location inquiry to be made to the LEC. Drop down box 126indicates that the information requested is a “descriptive address.”Other options in the drop down address may include a numbered address, aunnumbered address, cilli codes and ECCKT information (service ID). Dropdown box 128 provides a selection for the particular LEC from which theinformation is being requested. The customer premises address box is thebox in which the provisioner enters known information to obtain furtherlocation information. Since the “descriptive address” has been selectedin box 126, the provisioner, in this example, has selected a buildingname which is “St. Louis Union Station.” The provisioner also is awareof the postal code and that this building is located in Missouri. Whenother selections are made in the drop down box 126, other informationcan be included. For example, the name of the business customer may beincluded in the “CO. Name” box. The particular city in which thebusiness customer is located can also be included. Alternatively, theprovisioner can include ECCKT information in box 132. The provisionermay have particular ECCKT information for a desired location. The ECCKTinformation corresponds to a service ID, such as shown in box 124 ofFIG. 5. Similarly, location code information can be entered in box 134by the provisioner. The send box 136 can be activated by the provisionerto send a request through the system illustrated in FIG. 3 to the LECbackend.

[0050] The output choices box 138 of FIG. 6 shows a history of variouscalls that have been made to the LEC. The call corresponding to theinformation in the customer premises address box 130 is indicated on row140 of the output choices box 138. As seen on row 140, a response hasbeen returned as indicated in the status box of the output choices 138on row 140 which indicates “reply seen”. The LEC ID indicates theselected LEC and the date indicates the date and time of response. TheID number is the ID that is placed on the call by the prevalidationsystem 91. The data sent box indicates the customer premise addressinformation 130 that was sent in accordance with the information enteredin the customer premise address 130. By double clicking on row 140, thescreen indicated in FIG. 7 is produced.

[0051] The screen illustrated in FIG. 7 indicates the specific dataretrieved from the LEC for the “St. Louis Union Station” request. Thecustomer premise address output box 144 indicates the detailedinformation regarding the St. Louis Union Station address. As indicatedin box 144, a street name and address is provided the floor location androom number are also provided that indicates the location of theparticular equipment that has been searched. In other words, theinformation provided in box 144 indicates all the locations of all ofthe equipment at the St. Louis Union Station address.

[0052]FIG. 8 illustrates a service inquiry screen. The drop down box 146allows the provisioner to select a particular LEC for which the serviceinquiry is to be made. The “Service Available Inquiry Information” box148 is a box in which the provisioner can enter information regardingservice. As shown in FIG. 8, the service definition box 150 allows theprovisioner to indicate the type of service that is being sought. Asindicated in FIG. 8, an NC code of “HCMA” has been entered by theprovisioner. This NC code is an equipment indicator. The NCI codeof“02*” has been entered which constitutes a wildcard. Hence, all of theHCMA equipment will be provided by the LEC. The send box 152 is thenactivated by the provisioner. The output choices box 154 then indicatesthe status of the request. As indicated on row 156, the reply from theLEC has been received as indicated by the “reply completed” statussignal. The LEC ID field indicates the appropriate LEC. The date fieldprovides the date and time of the action indicated in the status box.The ID field constitutes the ID assigned by the prevalidation system 91.The NC/NCI field indicates the data that has been requested. By doubleclicking on line 156, the response is retrieved from storage in theprevalidation system 91 (FIG. 3) and the screen of FIG. 9 is produced.

[0053]FIG. 9 is a screen printout of a particular service inquiryrequest. As indicated in FIG. 9, the service inquiry request has an IDnumber of 10741. The service availability input box 158 indicates theinformation that was requested by the provisioner in accordance withFIG. 8. As shown, an NC number of “HCMA” was requested and the wildcard“02*” was requested for the NCI input. The service availability outputbox 160 indicates all of the HCMA information. For example, all of theNCI identification numbers for the HCMA equipment are provided.Additionally, the secondary NCI equipment information is also listed inthe NC/NCI field. Various specification information is listed in the“spec” field.

[0054]FIG. 10 is a schematic block diagram of the basic structure andfunctioning of the system of the present invention. As indicated in FIG.10, the basic structure illustrated in FIG. 3 is shown with additionaldetails. The provisioner 84 enters information on the interface device86 which may be logged onto the NetPro mainframe 88 to perform anintegrated process of prevalidation and ordering, or which may be loggedonto GUI client 204 to perform stand alone prevalidation requests. TheNetPro mainframe 88 is connected to a storage device 112 that archivesinformation relating the requests, orders and acknowledgments that havebeen made by the NetPro mainframe 88. The NDM interface device 108 isconnected to the secured line 110 that is connected to the backendsystems of the LEC 170. Orders and acknowledgments are transmittedbetween the backend of the LEC 170 and the NDM interface device 108 viathe secured line 110. Prevalidation requests and responses aresynchronously transmitted between gateway 92 of the inter exchangecarrier and a similar gateway of LEC 170 via secure line 106.Information from the gateway 92 is asynchronously communicated betweenthe ORB 174 and gateway 92 via 172. Prevalidation requests and responsesare transmitted between the ASR 176 and the NSS 178 synchronously.Similarly, prevalidation requests and responses are synchronouslycommunicated between NSS 178 and the integrated server 90. Theintegrated server 90 asynchronously communicates with the ORB 174 of theprevalidation system 91 via connection 180.

[0055] The ORB 174 of FIG. 10 functions as an interface for variousfunctions that are performed by the prevalidation system 91. Forexample, a local database 182 is connected through a database server 184to the ORB 174. The ORB constitutes middleware that employs the CORBAsoftware. The database server 184 and local database 182 constitute alocal database. This database stores all of the transactions that areperformed by the prevalidation system 91. The prevalidation system 91relies upon the database server 184 and local database 182 forpersistence so that if anything happens, the data has been stored in thelocal database 182. When a transaction is received by the prevalidationsystem 91, the first thing that occurs is that the transaction is storedto the database 182 so that it can be retrieved if there is a systemproblem. The database server 184 and local database 182 may also be usedfor auditing, as disclosed in more detail below.

[0056] Various system servers 186 also interface through the ORB 174, asillustrated in FIG. 10. For example, an alarm server 188 utilizes astandard third party tool called “Patrol” for its monitoring facilities190. Monitoring facilities 190 may, for example, monitor the connectionto the LEC. If the connection fails, then the monitoring facilities 190instruct the alarm server to set an alarm. The systems servers 186 alsoincludes a transaction log server 192 and a system log server 194. Thetransaction log server 192 logs each of the transactions that is placedthrough the prevalidation system 91 and stores this information in thelog and alarm database 196. Similarly, the system log server 194 logsall of the system's activities in the log and alarm database 196. Thealarm server 188 logs each of the alarms in the log and alarm database196. The metric server 198 determines metrics for the operation of thesystem illustrated in FIG. 10, including response times of the LEC 170.These metrics are also stored in the log and alarm database 196. Thismetric information can be very useful in analyzing the abilities andlimitations of the LEC backend systems. The metric system operates bymaking time stamps to determine how long it takes to process aprevalidation order through the prevalidation system 91. An accountingcan be made of the location of delays that occur both in theprevalidating system 91 and at the LEC. For example, the prevalidationsystem 91 may have very high volume that requires a queuing of a numberof calls which delays the system's operation. In this fashion, thedetermination can be made as to the apportionment of the delay periodbetween the prevalidation system 91 and the LEC.

[0057] As also shown in FIG. 10, the batch client 200 is a client thatoperates in conjunction with the NetPro mainframe 88 and storage device112 to provide reconciliation between the prevalidated responses and theASR acknowledgments, as disclosed in more detail below. The user server202 also interfaces with the ORB and functions as the interface for theprevalidation system 91. All of the external clients that access theprevalidation system 91 are processed by the user server 202. GUI client204 is also processed by the user server 202 and provides a GUIinterface for the stand alone inquiries that are made by the provisioner84.

[0058] As indicated above, the prevalidation system 91 operatesasynchronously. The gateway queues 206 of gateway 92 queue up theasynchronous responses transmitted by the prevalidation system 91 to thegateway 92. The synchronous gateway server 208 then interacts with theLEC 170 on a synchronous basis as indicated above. In this fashion, theasynchronous nature of the prevalidation system 91 can be maintained inan environment of synchronous communication with the LEC 170.

[0059] In operation, the provisioner 84 uses the interface device 85,such as a PC, that has a network connection 87. The network connection87 allows a provisioner 84 to log on to either the NetPro mainframe 88or into the prevalidation GUI client 204 to access the computing deviceson which the prevalidation system 91 is operating. By logging directlyinto the GUI client 204 of ORB 174, the provisioner can utilize the GUIclient 204 to make stand alone prevalidation requests, such asillustrated in FIGS. 4 through 9. When logging directly onto the NetPromainframe 88, the provisioner accesses the ASR 176 process to generateaccess service requests. The access service request process is anintegrated process that uses a series of electronic forms to generateaccess service requests. As each electronic form is completed, if theform contains prevalidated data, the ASR 176 automatically generatesprevalidation requests which may include a number of calls for thecurrent electronic form. Once the responses for the prevalidationrequest are received by the NetPro mainframe 88, an order is submittedthrough NDM 108 via secured line 110, as described above. In thisfashion, an integrated process of prevalidation and ordering is providedin accordance with the present invention. The stand alone prevalidationrequests that utilize GUI client 204 are used primarily by theprovisioner 84 to obtain information regarding available channels,location information, and service inquiry information, as indicatedabove, with respect to FIGS. 4 through 9.

[0060] In the process of placing an order that uses the systemillustrated in FIG. 10, the NetPro mainframe 88 utilizes NSS server 178to interface with the integrated server 90. The integrated server 90communicates with the ORB 174 using the CORBA middleware. However,integrated server 90 must communicate with the mainframe utilizing acommunications protocol compatible with the NSS server 178. AlthoughCORBA could be used on the NetPro mainframe 88 it is difficult andexpensive to implement. The NSS server 178 is based on OS/2 serverplatforms and functions as a middleware client server architecture. TheNSS server utilizes ABUs which are Atomic Business Units. As such,specific business logic runs on the NSS server 178. A module is createdin the NSS server 178 to communicate with the integrated server 90 via aTCP/IP socket call. In operation, the NetPro mainframe 88 makes a callto the ABU of the NSS server 178, and the ABU uses a TCP/IP socket callto the integrated server 90. The integrated server makes a socketavailable via TCP/IP protocol. Integrated server 90 translates the datafrom the TCP/IP socket call into the CORBA structures that can becommunicated through the ORB 174. The TCP/IP socket call provides datathat is in the form of a flat delimited string. The integrated server 90converts the flat delimited string of data into the CORBA data types.The integrated server 90 then makes a call into the prevalidation system91. The integrated server 90 is also able to communicate with the ORB174 an asynchronous manner, as indicated above. Hence, the integratedserver is able to deal with the synchronous transmission of data fromthe NSS server 178 and provide data to the ORB 174 asynchronously. Theintegrated server 90 holds the socket connection to the mainframe openwhile the integrated server 90 collects the responses returned from theORB 174. When the responses are received, the integrated server sends 90the response to the mainframe 88. In this fashion, the mainframe 88 canoperate synchronously while the integrated server 90 deals with theasynchronous aspects of the ORB system 174. It is important to note,however, that multiple inquiries can be made by the NSS server 178 intothe integrated server 90 while each call is being held open. In thisfashion, the NetPro mainframe 88 and the integrated server 90 canoperate with parallel requests and responses. The integrated server 90makes the multiple calls into the ORB 174 so that multiple calls may betransmitted through gateway 92 nearly simultaneously.

[0061] A reconciliation process can also be performed by the systemillustrated in FIG. 10. As indicated previously, storage device 112maintains all of the information regarding all of the orders andsupplemental orders that are processed by the ASR system 176, as well asall of the acknowledgments that are received from the LEC 170. Variousprograms that are run by the NetPro mainframe 88 accumulate that dataand generate a table of CFAs that are stored in storage 112. The tableof CFAs indicates all of the CFAs that are utilized by the interexchange carrier 78 (FIG. 3). In other words, the inter exchange carrier78 keeps track of the status of each of the CFAs including theassignments of channels for each CFA.

[0062] The reconciliation process utilizes this table of CFAs toreconcile the inter exchange carrier CFA data with the LEC CFA data. Anydifferences between this data can then be reconciled with the LEC. Thisreconciliation process can be performed using the functions of theprevalidation system 91.

[0063] The prevalidation system 91 may periodically generate a query tothe NetPro mainframe 88 to obtain the table of files that is stored instorage 112. These files are then FTP'd to the prevalidation system 91.The batch client 200 of the prevalidation system 91 then reads thesefiles. FIG. 11 illustrates a sample table of a series of CFAs to 20.FIG. 11 is a sample of what may appear as a much more comprehensivetable of files that is stored in storage device 112. As can be seen inFIG. 11, each CFA constitutes a separate row in FIG. 11 and includes thecircuit identification information. CFAs are stored in the table as anACSII file, as shown in FIG. 11.

[0064] As indicated above, the batch client 200 reads each of the CFAsline by line and generates prevalidation inquiries that are transmittedto the LEC in the manner described above. This occurs during slowperiods, such as at night when prevalidation system 91 is not in use.Since the LECs do not charge for prevalidation inquiries, the only costto the inter exchange carrier 78 is the cost of running theprevalidation system 91.

[0065] The LEC 170 provides responses in the manner described above.These responses are placed in a response file by the batch client 200. Atypical response file is shown in FIG. 12. As indicated in FIG. 11, oneof the CFAs is CFA 222. Referring to FIG. 12, the responses 224 from theprevalidation request for CFA 222 are provided. As shown in FIG. 12,channels 1, 2, and 3 are assigned. Channels 4 through 6 are sparechannels that are available for assignment. Further, channels 8, 14, 16,21, 22 and 24 are spare channels, while channels 7, 9 through 13, 15, 17through 20 and 23 have been assigned.

[0066] As also shown in FIG. 11, one of the CFAs is CFA 226. FIG. 12indicates the responses 228 for CFA 226 although not all of theresponses are shown. The response reports which is shown in FIG. 12 areFTP'd back to the mainframe 88. The mainframe then generates reportsthat show the differences between the CFA data that is stored in storagedevice 112 and the response files that are shown in FIG. 12. Themainframe 88 generates reports that only show the differences betweenthe response files of FIG. 12 and the CFA data that is stored in storagedevice 112. If differences exist, circuit IDs are compared with assignedpurchase order numbers to provide additional information regarding theassignment of channels for the CFA. Additionally, circuit informationmay be used to provide additional evidence of the assignment ofchannels. In one implementation, a temporary database is generated bythe NetPro mainframe 88 with the purchase order number associated withthe CFA and the channel assignments. A comparison can then be run and ifthere are differences, a purchase order number can be used to determinewhere the problem has originated. This information can then be used bypersonnel at the inter exchange carrier to either adjust the interexchange carrier database to correct a system error in the interexchange carrier system or adjust the database of the LEC. Further, thisinformation can be used to make billing corrections.

[0067] The invention illustrated in FIG. 10 can also perform auditingfunctions. As pointed out above, the system illustrated in FIG. 10 canoperate as an integrated prevalidation and ordering system in whichprevalidation requests and responses are automatically generated as eachelectronic form is completed when data is entered while placing anorder. As indicated above, prevalidation responses can be received priorto submitting each service order. The NetPro mainframe 88 generates afile of these prevalidation responses and the resultant service orderacknowledgments that are provided by LEC 170. Occasionally, an orderwill be prevalidated and an acknowledgment is returned that rejects theorder. Since the prevalidation has occurred just previously to theplacement of the order, the order should not have been rejected and theinter exchange carrier should not have to pay for a supplemental order.The file that is generated by the NetPro mainframe 88 includes each ofthe rejected acknowledgments and accepted prevalidation responses.Further, additional information may be provided such as purchase ordernumbers and other data fields such as the “Ver” field, the “Form ID”field, the “Field ID” field, the “Date and Time of Validation” field,the “Rave Request ID” field, the “Rave Response” field and the “UserAction” field. Upon acknowledgment, the ASR system determines the fieldthat is in error. The mainframe 88 then determines the correspondingresponse for this field from the database record. The ASR system thenupdates the file for this database pair with the error condition. Thiserror condition can be used for reporting purposes. The mainframe 88then generates a report that can be used for auditing costs that areincurred by the inter exchange carrier in generating a supplementalreport. The report includes information as to the number of ASRs thatwere rejected because of a provisioner override of an error condition.It may also report the number of ASRs that were rejected even though thevalidation process was successful. The ASR system can post the responsedata for user review. Information in the report is useful to determinewhether an action should be taken to call the LEC for explanation or tocorrect the ASR and resend the order. The report can be automaticallygenerated and sent to the billing department for auditing purposes or tothe LEC. The file, of course, can accumulate this data over a period oftime and then forward the report to the accounting office on a periodicbasis, such as once a week or once a month. In this fashion, theaccounting office can provide evidence for refund of charges onsupplemental orders.

[0068] Further, the NetPro mainframe 88 can store accepted prevalidationresponses that are received as part of the integrated prevalidation andordering process. In the process of generating prevalidation requests inthe integrated prevalidation and ordering system, each of theprevalidation requests can be compared to prevalidation responses thathave been previously accepted and stored in a file by mainframe 88. Ifthe circuit identification and channels of a subsequent prevalidationrequest are the same as a previously accepted prevalidation response, arejection signal can be generated by the NetPro mainframe 88 to preventthe submission of the service order. In other words, if the interexchange carrier has already prevalidated an order, that order isreserved in the system so that there are not conflicts between orders.

[0069] Of course, information stored in the files by the mainframe forboth the auditing and the prevalidation reservation processes includesinformation that must be provided by the prevalidation system 90.Queries may be made by the mainframe 88 to the prevalidation system 91.Specifically, these queries may be processed by the user server 202which generates a database call to the database server 184 and localdatabase 182. In this fashion, the data residing within theprevalidation system 91 can be provided to the mainframe 88 to providethe necessary data for the reconciliation files, the audit files and theprevalidation reservation files.

[0070] The present invention therefore provides a unique system that iscapable of providing an integrated process for prevalidation andordering, as well as providing for stand alone inquiries to obtaininformation from the LEC. The present invention is capable of providinga database of information that can be used by a provisioner to placeorders and reconciling that database with the LEC database to ensurethat proper information is provided. In this fashion, costs can begreatly reduced by avoiding the submission of supplemental orders thatare based upon incorrect information. Further, savings can be providedby identifying incorrect data that is being used by the LEC.

[0071] The present invention is also capable of providing auditinginformation that can be used to audit charges that have been incurred bythe inter exchange carrier as a result of a rejected acknowledgmentsthat have followed accepted prevalidation responses in the integratedprevalidation and ordering system. Reports can be generated that can beused by the accounting department and sent directly to the LEC forresolution. Additionally, a prevalidation request can be reserved in thesystem illustrated in FIG. 10 by storing a record of each prevalidationresponse that has been accepted and comparing them with each subsequentprevalidation request. In this fashion, conflicting requests that aremade at nearly the same time do not result in any overlap and will avoidsubmission of conflicting orders.

[0072] The foregoing description of the invention has been presented forpurposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise form disclosed, andother modifications and variations may be possible in light of the aboveteachings. The embodiments disclosed were chosen and described in orderto best explain the principles of the invention and its practicalapplication to thereby enable others skilled in the art to best utilizethe invention in various embodiments and various modifications as aresuited to the particular use contemplated. It is intended that theappended claims be construed to include other alternative embodiments ofthe invention except insofar as limited by the prior art

We claim:
 1. A method of auditing an integrated prevalidation and ordering system in which service orders are placed by an inter exchange carrier with local exchange carrier comprising: obtaining prevalidation responses and service order acknowledgments in response to generation of a service order on said integrated revalidation and ordering system; generating a file of said prevalidation responses and service order acknowledgments for each service order that has a rejected acknowledgment and an accepted prevalidation response; using said file to audit charges incurred by said inter exchange carrier for said service orders.
 2. The method of claim 1 further comprising: storing said accepted prevalidation responses; comparing each subsequent prevalidation request with said accepted prevalidation responses; generating a rejection signal whenever said subsequent prevalidation request includes circuit channels that have corresponded to circuit channels of said accepted prevalidation responses; preventing submission of said service order upon receipt of said rejection signal.
 3. The method of claim 1 wherein said step of obtaining prevalidation responses comprises: completing a plurality of electronic forms in said process of placing said service orders that provide data relating to said service order; prevalidating said data provided on each electronic form of said plurality of electronic forms as soon as said electronic form is completed.
 4. The method of claim 1 wherein said step of generating a file further comprises: attaching purchase order numbers to said service order acknowledgments and said prevalidation responses to assist in auditing charges incurred by said inter exchange carrier.
 5. A system for auditing charges incurred by an inter exchange carrier for supplemental orders necessitated by rejected acknowledgments of a service order that received an accepted prevalidation response in an integrated prevalidation and order system comprising: a prevalidation system that generates prevalidation requests and receives prevalidation responses in response to preparation of a service order in an integrated prevalidation and ordering system; an ordering system connected to said prevalidation system and a local exchange carrier that generates a file of accepted prevalidation responses and rejected service order acknowledgments, and generates a report from said file to audit said charges incurred by said inter exchange carrier.
 6. The system of claim 5 wherein said ordering system further comprises: a storage device for storing said files.
 7. The system of claim 5 wherein said prevalidation system further comprises: an object request broker that is coupled to said ordering system; a gateway that is coupled to said object request broker and another gateway utilized by said local exchange carrier.
 8. The system of claim 5 wherein said prevalidation system further comprises: a metric system that is capable of generating metric information regarding operation of said prevalidation system and said ordering system.
 9. The system at claim 5 wherein said ordering system further comprises: ordering system software for interfacing with said local exchange carrier to place orders; translation software that enables communication between said ordering system and said prevalidation system. 